\section{Introducción}

El sistema \textbf{El precio justo} está basado en la extracción de información a partir de la red social Twitter. En particular, se utilizarán aquellos tweets que contengan un cierto hashtag, para informar al usuario respecto de los lugares en donde éste puede conseguir determinados productos al precio más bajo.

El usuario tendrá la posibilidad de realizar consultas sobre determinados productos que sean de su interés y en base a distintos criterios como ser próximidad, área de búsqueda, precios máximos, etc. En principio, dicho sistema, contará solo con una cantidad fija de procutos y de criterios a utilizar, para luego ser extendido en etapas posteriores.

En este primer informe mostraremos la planificación del sistema en el cual incluímos el Product Backlog, con todas sus User Stories, y el Sprint Backlog correspondiente a la primer iteración de desarrollo.
De todas las User Stories mostraremos su estimación en Story Points y solo de aquellas que pertenezcan al primer Sprint detallaremos sus Tasks y las correspondientes estimaciones en horas. También en el presente informe describiremos las decisiones asumidas tanto para la estimación como para el funcionamiento del sistema propiamente dicho.
 

\section{Toma de decisiones}

A continuación describiremos las decisiones asumidas y aclaraciones con respecto al desarrollo de la primer entrega:

\begin{itemize}
 \item Utilización del servicio Google Maps tanto para facilitar la visualización de resultados en un mapa, como también para realizar cálculos de distancias, transformaciones de direcciones a coordenadas, identificación del área donde se encuentra una determinada dirección o coordenada, etc.
 
 \item Los criterios de búsqueda se seleccionarán y aplicarán individualmente a cada producto buscado y no sobre el total. Es decir que, por ejemplo, se puede buscar por un producto A gastando menos de \$X, por un producto B gastando menos de \$Y y por un producto C caminando lo menos posible.
 
 \item Los criterios de búsqueda $"$gastar menos de \$X$"$, $"$en un área determinada$"$, $"$gastando lo menos posible$"$ y $"$caminando lo menos posible$"$ podrán ser combinados entre sí, excepto $"$gastando lo menos posible$"$ y $"$caminando lo menos posible$"$, que no podrán ser usados en forma conjunta para un mismo producto.
 
 \item Con respecto al criterio de búsqueda sobre un área determinada, asumiremos que dicha área hace referencia a un barrio dentro de la Ciudad Autónoma de Buenos Aires. 
 
 \item Para el desarrollo de la primera iteración supondremos que los productos a utilizar están conformados por una sola palabra (por ejemplo se podrá utilizar el producto \textit{Zapallitos}, pero no \textit{Crema para rulos}).
 
  \item Si el usuario realiza una consulta en el sistema ingresando más de un producto, entonces se realizará una búsqueda individual por cada uno de ellos y los resultados se listarán respectivamente clasificados por producto buscado.
  
 \item El resultado de una búsqueda se mostrará, en principio, como una lista en donde se detallará la ubicación donde se puede obtener el producto y el precio del mismo. Para una próxima etapa se tendrá en cuenta mostrar los mismos en un mapa.
 
 \item En la user story \textbf{Flexibilidad en criterios de búsqueda} (US94) se identifica al cliente como el rol interesado en dicha funcionalidad. Sin embargo, creemos que esto constituye a su vez una fuerte sugerencia a tener en cuenta por los desarrolladores al momento de dise\~nar y resolver dicha user story.
 
 \item En el enunciado se describe que: \textit{"Para hacer más fácil la búsqueda se prorizarán mensajes que incluyan el hashtag \#precioJusto"}. Luego de analizarlo, hemos decidido tener en cuenta solamente aquellos tweets que contengan dicho hashtag, descartando todos los restantes, dado que consideramos excesivo el tener que procesar cualquier tipo de tweet que se publique en el mundo, con el objetivo de saber si representa un tweet de interés para nuestro sistema.
 
 \item Los tweets aceptados cumplen estrictamente con el formato "$<$ Producto $> <$ Precio $> <$Unidad $> <$ Lugar $>$", donde:
\begin{itemize}
 \item $<$Producto$>$ está en la lista de productos predefinidos.
 \item $<$Precio$>$ es un número entero o con 2 decimales delimitado por $","$ o $"."$. Debe estar seguido por la palabra $"peso"$ o $"pesos"$, o bien precedido por el símbolo $\$$ separado o no por un espacio.
\item $<$Unidad$>$ es válida para el tipo de producto.
\item $<$Lugar$>$ es una calle y una altura, separados por un espacio en blanco.
\end{itemize}
 y, por el momento, no consideraremos errors tipográficos y/o ortográficos 
 
\item Los productos pueden ser vinculados con ciertas unidades específicas. Es por esto, que debemos validar que en el tweet el producto y la unidad tengan sentido para poder ser considerado de interés para nuestro sistema (por ejemplo, no tiene sentido vincular la unidad \textit{Litros} con el producto \textit{Zapallitos}).

\item En las user stories correspondientes al primer Sprint se podrá encontrar una task descripta como "Testing". Dentro de la misma, se encuentra contemplada la generación de casos de prueba y, en consecuencia, su costo en tiempo al momento de estimarlas.

\item En una primer etapa, se realizará una interfaz de usuario de tipo linea de comandos. En una segunda etapa se realizará una interfaz gráfica, que permita ingresar los valores de cada criterio de búsqueda, y que permitirá mostrar los resultados en un mapa.

\end{itemize}

\section{Planificación}

\subsection{Product Backlog}

A continuación se muestra el total de los user stories generados para el desarrollo de este sistema.
De las user stories se muestra su nombre, la descripción, los criterios de aceptación y su estimación en story points.


\includepdf[pages={-}]{pdf/backlog.pdf}


\subsection{User values}

	\begin{tabular}{lll}
		US32	&	Obtención de Tweets																& 8 \\
		US34	& Procesamiento de Tweets - Etapa 1									& 5 \\
		US125	& Interfaz de usuario - Etapa 1											& 5 \\
		US33	& Búsqueda por productos														& 5 \\
		US27	& Restringir búsqueda para gastar menos de \$X			& 3 \\
		US28	& Restringir búsqueda a un área determinada					& 3 \\
		US29	& Interfaz de usuario - Etapa 2											& 8 \\
		US30	& Restringir búsqueda para gastar lo menos posible	& 3 \\
		US31	& Restringir búsqueda para caminar lo menos posible	& 3 \\
		US35	& Procesamiento de Tweets - Etapa 2									& 8 \\
		US36	& Tweets con errores																& 1 \\
		US37	& Utilización de Geo-Referenciación									& 1 \\
		US77	& Ingresar ubicación																& 3 \\
		US84	& API de Google Maps																& 3 \\
		US94	& Flexibilidad en criterios de busqueda							& 1 \\
	\end{tabular}

\subsection{Sprint}

Una vez finalizado el proceso de generar las user stories para nuestro Product Backlog y estimarlas, pasamos a ver cuales de ellas se asignarían al primer sprint. Luego de esto, realizamos la división de las mismas en tareas, procedimos a estimarlas en horas y a asignarlas entre los distintos miembros del equipo.
A continuación se muestra una tabla que detalla el sprint y luego, de manera más específica, cada una de las stories que forman parte del sprint junto con sus tareas.

\subsubsection{Sprint velocity}

	Definimos, para nuestro equipo de 4 personas, una velocidad por Sprint de 9 story points. Este número surgió a partir de una estimación de las tareas que creíamos posibles de terminar en el tiempo estipulado para el primer Sprint. Es un estimado que se irá ajustando a medida que el equipo se conozca y el proyecto crezca.

\includepdf[pages={-}]{pdf/sprint.pdf}


